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Die folgenden Angaben sind den vom An me I der eingereichten Unterlagen entnommen 

(5) Verfahren zur Fehlerprufung von echtzeitfahiger Systemsoftware 

(§) Bei sicherheitskritischen Anwendungen, etwa in der Ei- 
senbahnsignaltechnik, werden an die Systemsoftware (= 
Betriebssystemkernel +systemnahe Softwarekomponen- 
ten) der verwendeten Datenverarbeitungsanlagen sehr 
hohe Anforderungen an die Fehlerfreiheit gestellt. Die Sy- 
stemsoftware muB daher so grundlich wie moglich auf 
Fehler gepruft werden. ErfindungsgemaS werden Pruf- 
prozesse (PP1...PPm) im Wechsel mit Applikationsprozes- 
sen (AP1...APn) ausgefuhrt. Durch diese Prufung im lau- 
fenden Betrieb des Systems wird eine hohere Sicherheit 
erzielt, da dadurch auch das reale (Langzeit-)Verhalten 
des Gesamtsystems Oberpruft wird. 
Um Aussagen uber die Richtigkeit der Prufergebnisse ma- 
chen zu konnen, wird die Prufung vorzugsweise diversitar 
durchgefuhrt. Diversitat kann erzielt werden durch: 

- Verwendung einer zweiten, unterschiedlichen Datenver- 
arbeitungsanlage, auf der identische Prufprozesse durch- 
gefuhrt werden (Hardware-Diversitat); 

- Wiederholung des Prufprozesses zu einem Zeitpunkt, in 
dem sich der Applikationsprozeft in einem anderen Zu- 
stand befindet (Zustands-Diversitat); 

- quasi-gleichzeitige Durchfuhrung von unterschiedlich 
programmierten Prufprozessen, die die gleiche Funktion 
der Systemsoftware prufen (Software-Diversitat). 
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Beschreibung 

Die Erfindung betrifft ein Verfahren zur Fehlerpriifung 
von echtzeitfahiger Systemsoftware nach dem Oberbegriff 
des Anspruchs 1, eine Datenverarbeitungsanlage nach dem 
Oberbegriff des Anspruchs 7 sowie ein Programmodul fur 
eine Datenverarbeitungsanlage nach dem Oberbegriff des 
Anspruchs 10. 

Zur Steuerung und Uberwachung sicherheitskritischer 
Systeme, etwa im Bereich der Eisenbahnsignaltechnik oder 
der Luft- und Weltraumfahrt, werden in der Regel echtzeit- 
fahige Datenverarbeitungsanlagen eingesetzt Eine Daten- 
verarbeitungsanlage - dabei kann es sich um einen einzel- 
nen Rechner oder auch um ein Mehrrechnersystem handeln 
- wird als echtzeitfahig bezeichnet, wenn teste Antwortzei- 
ten garantieren werden konnen. Dies bedeutet, daB die Zeit 
zwischen der Eingabe von Daten und der Ausgabe des zuge- 
horigen Ergebnisses bei fehlerfreiem Betrieb einen festen 
Wert unter keinen Umstanden uberschreitet. 

Die Echtzeitfahigkeit und die Sicherheitsverantwortung 
derartiger Datenverarbeitungsanlagen stellen hohe Anforde- 
rungen an die verwendete Hardware, vor allem jedoch an 
die eingesetzte Systemsoftware. Dies hat u. a. zur Folge, daB 
fur diese Anwendungen vorgesehene Systemsoftware be- 
sonders zuverlassig auf mogliche Fehler zu iiberpriifen ist 
Der BegrifF Systemsoftware wird im folgenden als Oberbe- 
griff fur den Betriebssystem- Kernel und andere systemnahe 
Softwarekomponenten (z. B. Schnittstellentreiber oder Ser- 
ver fur Queues, Timer usw.) verwendet. 

Aus einem Aufsatz von M. A. Tsoukarellas et al. mit dem 
Titel "Systematically Testing a Real-Time Operating Sy- 
stem", IEEE Micro, vol. 15, nr. 5, p. 50-60, Oct 1995, ist 
ein Verfahren zum Testen von echtzeitfahigen Betriebssy- 
stemen bekannt. Bei diesem Verfahren werden zunachst ein- 
zelne Funktionen, anschlieBend aus diesen Funktionen zu- 
sammengesetzte Module und schlieBlich das aus den Modu- 
len bestehende Gesamtprogramm getesteL Zur Anwendung 
kommen dort sowohl sog. "black-box"- als auch "white- 
box"-Tests. Dort wird femer beschrieben, daB zum Testen 
ein zusatzlicher Rechner verwendet wird, der fur den Rech- 
ner mit dem eigentlich zu testenden Betriebssystem die Au- 
Benweit (ProzeBparameter ect) simuliert 

Eine der charakteristischen Eigenschaften von echtzeitfa- 
higer Systemsoftware ist es, daB es Typen von Fehlem gibt, 
die nur in bestimmten komplexen Betriebszustanden auftre- 
ten. Der bei dem bekannten Testverfahren eingesetzte Rech- 
ner, der die AuBenwelt simulieren soli, ist im Regelfall nicht 
in der Lage, diese komplexen Betriebszustande zu reprodu- 
zieren. Es ist daher Aufgabe der Erfindung, die Fehlerprii- 
fung von echtzeitfahiger Systemsoftware zuverlassiger zu 
machen. 

Die Aufgabe wird gelost durch ein Verfahren nach An- 
spruch 1, eine Datenverarbeitungsanlage nach Anspruch 7 
und ein Programmodul nach Anspruch 10. Erfindungsge- 
maB werden Applikationsprozesse im Wechsel mit Prufpro- 
zessen von der Datenverarbeitungsanlage ausgefuhrt. Damit 
wird erreicht, daB auch wahrend des regularen Betriebs 
("Feldeinsatz") der Datenverarbeitungsanlage eine Fehler- 
priifung der Systemsoftware stattfindet. Da sich die Daten- 
verarbeitungsanlage wahrend des Feldeinsatzes in den ver- 
se hiedensten Betriebszustanden befindet, lassen sich durch 
das erfindungsgemaBe Verfahren Fehler wesentlich zuver- 
lassiger entdecken als dies bei Verfahren der Fall ist, die von 
einer kunstlich geschaffenen Testumgebung ausgehen. Ein 
weiterer bedeutender Vorteil besteht darin, daB auch solche 
Fehler aufspurbar sind, die sich erst nach langerer Betriebs- 
dauer einstellen. So sind beispielsweise Fehler bei der Zu- 
weisung von Speicherplatz bekannt geworden, die sich erst 
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nach einem Dauerbetrieb von vielen Tagen, Wochen oder 
gar Monaten bemerkbar machen. Derartige Fehler lassen 
sich mitHilfedes erfindungsgemaBen Verfahrens aufspiiren, 
wahrend bekannte, vor dem Feldeinsatz durchgefuhrte Tests 
5 in aller Regel nur Fehler entdecken konnen, die unmittelbar 
nach Betriebsaufhahme in Erscheinung treten. 

Bei einer vorteilhaften Ausfuhrung des Verfahrens nach 
Anspruch 2 werden die Prufprozesse wahrend des Feldein- 
satzes diversitar durchgefuhrt Hierfur sind verschiedene 
10 Varianten vorgesehen, die Gegenstand der Anspruche 3 bis 
5 sind. Aufgrund der Diversitat kann die Zuverlassigkeit der 
Fehlerprufung weiter verbessert werden, da ein Vergleich 
der Priifergebnisse von wenigstens zwei Prufprozessen 
durchgefuhrt wird. 
15 Die Erfindung wird nachfolgend anhand der Ausfuh- 
rungsbeispiele und der Zeichnungen eingehend erlautert Es 
zeigen: 

1 Fig. 1 Schematische Darstellung des Schichtenmodells 
eines Rechners R zur Erlauterung des erfindungsgemaBen 
20 Verfahrens, 

Fig, 2 Vereinfachte Darstellung zur Erlauterung, wie 
Applikadons- und Prufprozessen von einem Scheduler Zeit- 
schlitze zugeordnet werden konnen, 

Fig. 3 Eine Fig. 1 entsprechende Darstellung eines Rech- 
25 ners, der zusatzlich PriifprozeBsteuerungsmittel PPSM um- 
faBt, 

Fig. 4 Schemadsche Darstellung zweier Rechner Rl und 
R2 zur Erlauterung des Ausfuhrungsbeispiels nach An- 
spruch 3, 

30 Fig. 5 Zuordnung von Zeitschlitzen zu Applikadons- und 
Prufprozessen nach einem Ausfuhrungsbeispiel gemaB An- 
spruch 4, 

Fig. 6 Zuordnung von Zeitschlitzen zu Applikadons- und 
Prufprozessen nach einem Ausfuhrungsbeispiel gemaB An- 
35 spruch 5. 

Fig. 1 zeigt schematisch ein Schichtenmodell eines Rech- 
ners R zur Erlauterung des erfindungsgemaBen Verfahrens. 
Auf einer Hardwareschicht HW setzt die Systemsoftware 
SS auf, die den Betriebssystem- Kernel OS im engeren Sinne 
40 sowie weitere systemnahe Software SNS umfaBt. Die Sy- 
stemsoftware SS kommuniziert mit dariiberliegenden App- 
likationsprozessen API. . .APn. Applikationsprozesse sind 
Programme oder Teile von Programmen, die in sich abge- 
schlossene Einheiten darstellen. Insbesondere kann ein ein- 
45 zelner ApplikadonsprozeB iiber den gesamten ihm zugewie- 
senen Speicherbereich des jeweiligen Rechners eigenstan- 
dig verfugen. Der Daten austausch zwischen der Systemsoft- 
ware SS und den Applikationsprozessen kann gegebenen- 
falls iiber eine Programmierschnittstelle API erfolgen, wor- 
50 auf unten naher eingegangen werden wird. 

Durch den Pfeil PF1 ist angedeutet, daB bei der Ausfuh- 
rung von Applikationsprozessen sowohl die Systemsoft- 
ware SS als auch die Hardwareschicht HW beteiligt ist. So 
wird etwa bei einem Funktionsaufruf durch einen Applikati- 
55 onsprozeB zunachst von der Systemsoftware SS ein von der 
Hardwareschicht lesbarer Befehl erzeugt und dieser dann 
von der Hardwareschicht ausgefuhrt. Das von der Hardwa- 
reschicht ermittelte Ergebnis wird anschlieBend von der Sy- 
stemsoftware SS in eine Form zuriickverwandelt, die vom 
60 ApplikationsprozeB verstanden wird. 

ErfindungsgemaB ist nun vorgesehen, neben den Applika- 
tionsprozessen API. . .APn noch weitere Prozesse auszu- 
fuhren, die als Prufprozesse PPL . .PPm bezeichnet werden. 
Die Prufprozesse werden im Wechsel mit den Applikations- 
65 prozessen API. . .APn ausgefuhrt und haben die Aufgabe, 
Fehler in den darunterliegenden Schichten aufzuspiiren. Bei 
der Ausfuhrung der Prufprozesse sind - wie auch bei den 
Applikationsprozessen - alle darunterliegenden Schichten 
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beteiligt. Wenn ein Fehler festgeslellt wird, so ist es daher 
zunachst nicht moglich, diesen der Hardwareschicht HW 
oder der Systemsoftware SS zuzuordnen. Wenn jedoch zu- 
satzlich auf der Ebene der Systemsoftware eine Priifung der 
darunterliegenden Hardwareschicht stattfindet, so konnen - 5 
sofern die Hardwareschicht HW fehlerfrei ist - von den 
Priifprozessen PP1. . .PPm entdeckte Fehler zuverlassig der 
Systemsoftware SS zugeordnet werden. Von der System- 
software gesteuerte Verfahren zur Priifung der Hardware- 
schicht sind dem Fachmann bekannt, ohne daB es hierfur ei- 10 
nes weiteren Nachweises bedarf. 

Die Priifprozesse PP1 . . .PPm unterscheiden sich grund- 
satzlich nicht von solchen Priifprozessen, die nach her- 
kornmlicher Art vor dem Feldeinsatz "im Labor" durcbge- 
fiihrt werden, um die Systemsoftware zu iiberpriifen. Es IS 
wird daher darauf verzichtet, einzelne Priifprozesse einge- 
hend zu erlautern. Eine Ubersicht iiber mogliche Priifpro- 
zesse findet sich in einer Testsuite des National Institute of 
Standards and Technology rnit dem Titel: "NIST-PCTS: 
151-2", NIST POSIX Certification Authority, National In- 20 
stitute of Standards and Technology, Computer Systems La- 
boratory, Gaitherburg, MD 20899. Dort sind Priifprozesse 
aufgefuhrt, die durch mehrere Testfalle Funktionen folgen- 
der Funktionsgruppen auf ihre Richtigkeit hin iiberpriifen: 
Process Primitives, Process Environments, Files and Direc- 25 
tories, Input and Output Primitives, Message Queues, 
Clocks and Timers sowie Pthreads. 

Der Wechsels zwischen Applikations- und Priifprozessen 
kann auf verschiedene Weisen erfolgen. So kann z. B. vor- 
gesehen sein, daB der Rechner R immer im Wechsel einen 30 
vollstandigen ApplikationsprozeB und einen vollstandigen 
PriifprozeB ausfiihrt. Je nach Umfang der Priifprozesse kann 
dadurch jedoch die Abarbeitung der Applikationsprozesse 
fiir langere Zeit unterbrochen werden, was bei echtzeitfahi- 
gen Systemen u. U. nicht tolerierbar ist. Daher wird vor- 35 
zugsweise vom bei Echtzeitanwendungen iiblichen Zeit- 
schranken-Scheduling Gebrauch gemacht Beim Zeit- 
schranken- Scheduling werden den einzelnen Prozessen 
Zeitschranken fiir die Abarbeitung vorgegeben. Auf das er- 
findungsgemaBe Verfahren angewandt bedeutet dies, daB 40 
den Priifprozessen Zeitschlitze fester Lange zugeordnet 
werden. Nur innerhalb dieser Zeitschlitze stehen die Sy- 
stemresourcen (Prozessorleistung, Speicher etc.) den Priif- 
prozessen zur Verfugung; wahrend der restlichen Zeit wer- 
den Applikationsprozesse abgearbeitet. 45 

Eine mogliche Zuordnung der Zeitschlitze zu Applikati- 
ons- und Priifprozessen zeigt Fig. 2. Die Zeitschlitze haben 
in diesem Beispiel eine Lange von jeweils 1 ms. Ein Sche- 
duler stellt jeden vierten Zeitschlitz Priifprozessen zur Ver- 
fugung, wahrend die iibrigen Zeitschlitze der Ausfuhrung 50 
von Applikationsprozessen vorbehalten sind. Im dargestell- 
ten Beispiel wird ein ApplikationsprozeB API in 7 Teilpro- 
zesse APli. . .API7 unterteilt, die der Reihe nach abgearbei- 
tet werden. Dazwischen werden Teilprozesse PPli und PPI2 
eines Prufprozesses abgearbeitet Nach beendeter Ausfuh- 55 
rung des Applikationsprozesses API wird mit dem ersten 
TeilprozeB AP2! des nachsten Applikationsprozesses AP2 
begonnen usw. 

Zur Steuerung des Wechsels zwischen Applikations- und 
Priifprozessen kann ein zusatzliches PrufprozeBsteuerungs- 60 
modul PPSM verwendet werden. Das PriifprozeBsteue- 
rungsmodul PPSM gehort, wie dies in Fig. 3 erkennbar ist, 
zur Systemsoftware und kann auf Funktionen zugreifen, die 
von systemnahen Softwarekomponenten SNS bereitgestellt 
werden. Dem PrufprozeBsteuerungsmodul PPSM obliegt 65 
die Aufgabe, die Reihenfolge und Prioritat der Priifprozesse 
festzulegen. So ist etwa denkbar, daB die Priifprozesse wah- 
rend der vom Scheduler zugewiesenen Rechenzeit in fester 
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Reihenfolge nacheinander ausgefuhrt werden. Ebenso je- 
doch konnte die Ausfuhrung eines bestimmten Prufprozes- 
ses abhangig gemacht werden vom Vorliegen eines be- 
stimmten Systemkontextes. So ist es beispielsweise mog- 
lich, daB die Applikationsprozesse selbst den Aufruf be- 
stimmter Priifprozesse veranlassen. 

Bei einem Ausfuhrungsbeispiel der Erfindung nach An- 
spruch 2 werden die Priifprozesse diversitar ausgefuhrt In 
diesem Zusammenhang bedeutet Diversitat daB jeder Priif- 
prozeB wenigstens zweimal unabhangig voneinander ausge- 
fuhrt wird. Durch die diverse Ausfuhrung der Priifprozesse 
wird die Zuverlassigkeit der Fehlerprufung weiter erhoht 
Dabei wird angenommen, daB bei einem Fehler in der Sy- 
stemsoftware die Ergebnisse der Priifprozesse aufgrund der 
Diversitat voneinander abweichen. Folglich ist bei diverser 
Ausfuhrung von Priifprozessen dafur zu sorgen, daB die Er- 
gebnisse der entsprechenden Priifprozesse miteinander ver- 
glichen werden. Nachfolgend werden verschiedene Mog- 
lichkeiten erlautert, wie diese Diversitat erzielbar ist 

Fig. 4 zeigt schematisch einen Rechner Rl sowie einen 
zweiten Rechner R2. Der Obersicht halber ist der DatenfluB 
innerhalb der Rechner nicht dargestellt Die beiden Rechner 
Rl und R2 haben die gleiche Systemsoftware SS; gleich 
sind auch die von den Rechnern ausgefuhrten Applikations- 
und Priifprozesse API. . .APn bzw. PP1. . .PPm. Die Rech- 
ner haben lediglich eine Hardware HW1 und HW2, die sich 
moglichst deutlich voneinander unterscheidet (z. B. unter- 
schiedlicher Prozessortypen). Man konnte daher diese Art 
der Diversitat als "Hardware-Diversitat" bezeichnen. Sie ist 
besonders geeignet das Zus ammen wirken der Systemsoft- 
ware mit der Hardwareschicht zu iiberpriifen. Die Ergeb- 
nisse der Priifprozesse werden zwischen den Rechnern iiber 
eine Kommunikationsverbindung KOM ausgetauscht Auf 
diese Weise kann jeder Rechner erkennen, ob ein Priifpro- 
zeB PPi auf beiden Rechnern zu iibereinstimmenden Ergeb- 
nissen gefuhrt hat. Unterscheiden sich die Ergebnisse, so 
muB ein Fehler vorliegen. Eine zuverlassige Fehlerlokalisa- 
tion ist auf diese Weise nicht moglich, doch kann bei sorg- 
faltiger Priifung der verwendeten Hardware vermutet wer- 
den, daB der Fehler im Zusammenwirken zwischen Hard- 
ware und Systemsoftware zu suchen ist 

Eine andere Moglichkeit, Priifprozesse divers auszufuh- 
ren, besteht darin, einen bestimmten PriifprozeB zu wieder- 
holen und die Ergebnisse der Priifungen miteinander zu ver- 
gleichen. Vorausgesetzt wird dabei, daB sich der Rechner 
zum Zeitpunkt der Wiederholung in einem anderen Zustand 
befindet als zum Zeitpunkt der erstmaligen Durchfiihrung. 
Diese Art von Diversitat konnte man als "Zustands-Diversi- 
tat" bezeichnen. Im allgemeinen nimmt der Rechner wah- 
rend der Abarbeitung von Applikationsprozessen laufend 
andere Zustande ein, da sich etwa die Speicherbelegung 
wahrend der Abarbeitung fortwahrend andert Demnach 
wiirde es bereits ausreichen, einen PriifprozeB in kurzern 
zeitlichen Abstand zu wiederholen. Es gibt jedoch auch 
Applikationsprozesse, bei denen sich der Zustand des Rech- 
ners iiber einen langeren Zeitraum hinweg nicht andert Da- 
her ist es vorzuziehen, den PriifprozeB erst dann zu wieder- 
holen, wenn der Rechner einen anderen ApplikationsprozeB 
gerade bearbeitet oder bearbeitet hat Es ist dann sehr viel 
wahrscheinlicher, daB sich der Rechner in einem anderen 
Zustand befindet 

Dies sei anhand der Fig. 5 noch einmal erlautert. Fig. 5 
zeigt eine Zuordnung von Applikations- und Priifprozessen 
zu Zeitschlitzen ahnlich wie in Fig. 2. Der Einfachheit hal- 
ber sei angenommen, daB der PriifprozeB PPI lediglich ei- 
nen Zeitschlitz zur Ausfuhrung benotige. Der PriifprozeB 
PPI wird zunachst wahrend der Ausfuhrung des Applikati- 
onsprozesses API ausgefuhrt Dies ist in Fig. 5 daran er- 
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kennbar, daB vor bzw. nach dem mil PP1 gekennzeichneten 
Zeitschlitz 4 die zum ApplikationsprozeB API gehdrenden 
Teilprozesse API 3 und AP1 4 ablaufen. Bei der wiederholten 
Ausfuhrung des Priifprozesses PP1 befindet sich der Rech- 
ner bereits in eiDem anderen Zustand, da er nun den Appli- 5 
kationsprozeB AP2 ausfiihrt Dies ist daran erkennbar, daB 
vor bzw. nach dem mit PP1 gekennzeichneten Zeitschlitz 8 
die zum ApplikationsprozeB AP2 gehorenden Teilprozesse 
AP22 und AP2 3 ablaufen. 

Eine weitere Moglichkeit zur diversen Ausfuhrung von 10 
Prufprozessen besteht darin, zeitgleich oder an n ah era d zeit- 
gleich neben einem bestirnmten PriifprozeB PPi einen weite- 
ren PriifprozeB PPi' auszufuhren. Der weitere PriifprozeB 
PPi' uberpriift die gleiche Funktion der Systemsoftware wie 
der PriifprozeB PPi, ist jedoch divers zum PriifprozeB PPi 15 
programmiert. Diese Art der Diversitat sei nachfolgend 
"Software-Diversitat" genannt Mit dieser Art von Diversi- 
tat lassen sich u. U. auch solche Fehler in der Systemsoft- 
ware erkennen, die aufrund einer fehlerhaften Programmie- 
rung des entsprechenden Priifprozesses unentdeckt blieben. 20 

Zur Erlauterung zeigt Fig* 6 eine Zuordnung von Appli- 
kations- und Priifprozessen zu Zeitschlitzen ahnlich wie in 
den Fig. 2 und 5. Der PriifprozeB PPI und der dazu divers 
programmierte PriifprozeB PPI' werden hier in zwei aufein- 
anderfolgenden, fur die Ausfuhrung von Priifprozessen re- 25 
servierten Zeitschlitzen 4 bzw. 8 ausgefuhrt. Es sei auch hier 
der Einfachheit halber angenommen, daB zur Ausfuhrung 
der beiden Priifprozesse nur jeweils ein Zeitschlitz benotigt 
wird. Quasi-gieichzeitig dazu wird der ApplikationsprozeB 
API in den ubrigen Zeitschlitzen 1-3, 5-7, 10. . . ausge- 30 
fuhrt. 

Vorzugsweise werden die oben erlauterten Moglichkei- 
ten, eine Diversitat zu erzielen, miteinander kombiniert So 
ist es beispielsweise moglich, einen zu einem ersten Priif- 
prozeB PPI clivers programmierten PriifprozeB PPI* auf ei- 35 
nem zwei ten Rechner auszufuhren, der eine unterschiedli- 
che Hardware hat und auf dem unterschiedliche Applikati- 
onsprozesse ausgefuhrt werden. Eine solches Vorgehen 
macht von der Hardware-Diversitat, der Zustands-Diversitat 
und der Software-Diversitat Gebrauch. 40 

Die von den Priifprozessen zu priifenden Funktionen der 
Systemsoftware kann auf solche Funktionen beschrankt 
werden, die nicht vor dem Feldeinsatz der Datenverarbei- 
tungsanlage in ausreichender Tiefe priifbar sind. Beispiele 
hierfur waren etwa Funktionen fur Timer, Verwaltung von 45 
Massage-Queues oder Mechanismen der Ein- und Ausgabe. 
Dies ist dann sinnvoll, wenn aufgrund knapper Systemre- 
sourcen die Ausfuhrung von Applikationsprozessen mdg- 
lichst wenig durch die zusatzliche Ausfuhrung von Priifpro- 
zessen beeintrachtigt werden soli. 50 

Vorzugsweise kommunizieren die Applikations- und die 
Priifprozesse mit der Systemsoftware iiber eine definierte 
echtzeitfahige Progranirnierschnittstelle. Derartige Pro- 
grammierschnittstellen stellen darauf aufbauenden Prozes- 
sen einen normierten Satz von iiber definierte Befehle auf- 55 
rufbare Funktionen zur Verfugung. Wenn Applikationspro- 
zesse iiber Programmierschnittstellen mit darunterliegenden 
Schichten kommunizieren, so konnen die Applikationspro- 
zesse ohne Umcodierung bei einem Wechsel der darunter- 
liegenden Komponenten, etwa der Hardware oder der Sy- 60 
stemsoftware, weiter verwendet werden. Eine Programmier- 
schnittstelle heiBt normiert, wenn der Befehlssatz einheit- 
lich festgelegt und somit unveranderlich ist. Ein Beispiel fur 
eine derartige normierte echtzeitfahige Programmierschnitt- 
stelle ist ausfuhrlich beschrieben in B. O. Gallmeiser, "PO- 65 
SDC.4: Programming for the Real World", O'Reilly & Asso- 
ciates, Inc., 1995. Definiert ist diese Schnittstelle in IEEE 
Standard 1003.1b, Institute of Electrical and Electronics En- 
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gineers, Inc. Bei Verwendung einer Programmierschnitt- 
stelle nach diesem Standard rufen sich die Applikationspro- 
zesse iiber Botschaften auf, die in Warteschlangen abgelegt 
und sequentiell abgearbeitet werden ("Message-Queues"). 

Patentanspriiche 

1. Verfahren zur Fehlerprufung von echtzeitfahiger 
Systemsoftware (SS in Fig. 1) einer Datenverarbei- 
tungsaniage (R), auf der Applikationsprozesse 
(API. . .APn) ausgefuhrt werden, dadurch gekenn- 
zeichnet, daB im Wechsel mit den Applikationsprozes- 
sen ein PriifprozeB (PPI) ausgefuhrt wird, der wenig- 
stens eine Funktion der Systemsoftware iiberpriift. 

2. Verfahren nach Anspruch 1, bei dem der PriifprozeB 
die wenigstens eine Funktion der Systemsoftware di- 
versitar uberpriift. 

3. Verfahren nach Anspruch 2, bei dem die Diversitat 
dadurch erzielt wird, daB ein identischer PriifprozeB 
auf einer von der einen Datenverarbei tungsanlage (Rl 
in Fig, 4) sich unterscheidenden zwei ten Datenverar- 
bei tungsanlage (R2) ausgefuhrt wird, die eine identi- 
sche Systemsoftware (SS) hat. 

4. Verfahren nach Anspruch 2, bei dem die Diversitat 
dadurch erzielt wind, daB ein PriifprozeB (PPI in Fig. 5) 
wiederholt wird, wenn die Datenverarbeitungsanlage 
sich in einem anderen Zustand befindet. 

5. Verfahren nach Anspruch 2, bei dem die Diversitat 
dadurch erzielt wird, daB die Datenverarbeitungsanlage 
zusatzlich zu dem einen PriifprozeB (PPI in Fig. 6) ei- 
nen weiteren PriifprozeB (PPI') ausfiihrt, welcher die 
gleiche wenigstens eine Funktion der Systemsoftware 
wie der eine PriifprozeB uberpriift, aber divers zu dem 
einen PriifprozeB programmiert ist. 

6. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem nur solche Funktionen der Systemsoft- 
ware iiberpriift werden, die nicht vor einem Feldeinsatz 
priifbar sind. 

7. Datenverarbeitungsanlage (R in Fig. 1) mit einer 
echtzeitfahigen Systemsoftware (SS) zur Ausfuhrung 
von Applikationsprozessen (API. . .APn), dadurch ge- 
kennzeichnet, daB die Datenverarbeitungsanlage Pro- 
grarnmittel zur Ausfuhrung eines Priifprozesses (PPI) 
hat, der im Wechsel mit den Applikationsprozessen 
ausfuhrbar ist und der Uberpriifung wenigstens einer 
Funktion der Systemsoftware dient. 

8. Datenverarbeitungsanlage nach Anspruch 7, die 
Steuermittel (PPSM in Fig. 3) hat, die den Wechsel 
zwischen dem PriifprozeB und den Applikationspro- 
zessen steuern. 

9. Datentrager mit einem darauf gespeicherten Pro- 
gramm zur Ausfuhrung in einer Datenverarbeitungsan- 
lage, die eine echtzeitfahige Systemsoftware (SS) hat 
und auf der Applikationsprozesse (API. . .APn) ausge- 
fuhrt werden, dadurch gekennzeichnet, daB das Pro- 
gramm einen Wechsel zwischen Applikationsprozes- 
sen und einem PriifprozeB (PPI) steuert, welcher we- 
nigstens eine Funktion der Systemsoftware iiberpriift. 

10. Programmodul zur Ausfuhrung in einer Datenver- 
arbeitungsanlage, die eine echtzeitfahige Systemsoft- 
ware hat und auf der Applikationsprozesse ausgefuhrt 
werden, dadurch gekennzeichnet, daB das Programm- 
modul Steuerbefehle umfaBt, die einen Wechsel zwi- 
schen Applikationsprozessen und einem PriifprozeB 
steuem, welcher wenigstens eine Funktion der System- 
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